In this information age, businesses and other organizations regularly deal with large quantities of data. In order to access this data rapidly, organizations typically store the data in a computer-managed data repository such as a database or file system. A discrete unit of data stored in a repository may be referred to as an “information item.” For example, a business may store, in a database, information items related to purchase orders received from customers. When information about a particular purchase order should be updated, the information item corresponding to the particular purchase order may be selected and updated in the repository. For example, at the time a customer's order is shipped, the information item corresponding to the order may be updated to indicate a date and tracking number corresponding to the shipment.
As time goes by, the quantity of data stored by an organization tends to grow. For example, as customers place more and more orders with a business, the business typically stores more and more purchase order information items in its repository. As the amount of data in a repository increases, the performance of the repository decreases. For example, a query performed on a database with many information items typically takes longer to complete than the same query performed on a database with few information items. The quantity of data in a repository also influences the time required to backup the data within the repository and the time required to recover such data should a fault occur relative to the repository.
By moving data from a first repository to a second repository, the quantity of data stored in the first repository may be maintained at a manageable size. However, application programs (“applications”) that access the data might still need to access data that has been moved out of the first repository, as well as data that has been retained in the first repository. Many applications might not be designed or configured to access data in multiple repositories. If an application is configured to access only a single repository, and the data needed by that application has been moved to another, different repository, then the application may fail to find some or all of the data that the application needs. This can lead to unexpected and incorrect results.
One possible solution might be to modify existing applications so that those applications are able to access multiple repositories. Unfortunately, such modification can be expensive and time-consuming. Businesses that have already spent considerable resources in acquiring, installing, and using existing applications are often loath to expend additional resources to acquire, install, and use revised editions of those applications. Additionally, it can be difficult for application programmers to foresee and address all of the many different repository system configurations that an application might encounter. End users of applications typically would rather not be forced to specially configure those applications to work with their specific repository system configurations. Thus, a technique that overcomes the limitations of prior approaches to accessing data distributed among multiple data repositories is needed.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.